第1章 小さくまとめてわかりやすくする
プログラムの変更が楽になる書き方
わかりやすい名前を使う
長いメソッドは「段落」に分けて読みやすくする
空白行
（段落分けという意図を持って空白行を入れる！）
目的ごとに変数を用意する
変数を使い回さない
目的別に専用のローカル変数を用意し、コードの意図を変数名で説明するこのやり方を説明用の変数の導入と呼びます。(Kindle の位置No.514-516)
メソッドとして独立させる
異なるクラスにある重複コードをなくす
共通クラスに抽出している
小さなクラスでわかりやすく安全に
複雑さを閉じ込める
配列やコレクション型を操作するロジックを、専用の小さなクラスにまとめて整理する (Kindle の位置No.782-783)
コレクションオブジェクト（ファーストクラスコレクションとも）
値オブジェクトと同じ考え方
使う側のコードが単純になる（オブジェクト指向設計のコツ）
コレクションを操作するコードがあちこちに散らばらない・重複しない
コレクションオブジェクトは、そういう重要な業務の関心事を表現する手段であり、同時に業務ロジックをわかりやすく整理し、コードの変更を楽で安全にする工夫なのです。(Kindle の位置No.877-879)
例：顧客一覧の専用クラス Customers
（IMO：一覧の専用というのが興味深い）
「業務の関心事」と、プログラミング単位である「クラス」を1対1に対応させる工夫 (Kindle の位置No.873-874)
List<Customer>を操作するロジックは、すべてこのCustomersクラスに集めます (Kindle の位置No.806)
複雑さを閉じ込めた
メンバ変数はList<Customer>のみ（ほかには持たない）
不変にして安定させる
List<Customer>への参照をそのまま外部へ返さない
外部でCustomersクラスの属性を書き換えることができてしまうため（＝安定しない）
List<Customer>（コレクションへの参照）を返したときにやりたい操作をコレクションオブジェクトに持たせる
コレクション操作の結果を新しいコレクションオブジェクトを作って返す（例：addメソッド）
値オブジェクトと同じ
現在のコレクション内容と状態が異なるコレクションは、別のオブジェクトになります。(Kindle の位置No.848-849)
どうしてもList<Customer>を返したい場合
変更不可のコレクションに変換して返す（Collections.unmodifiableList）
かつ、（unmodifiableListでも個々の要素は変更できるので）個々の要素を値オブジェクトにして不変にする